NONE
The present invention relates generally to Advanced Intelligent Networks (AIN). More particularly, the invention relates to a method for merging calls using the equipment associated with an AIN to free up resources.
An AIN is a service-independent architectural concept for telecommunication networks. Its objectives include the easy development of new and innovative feature-rich services, reducing the turn-around time for the introduction or modification of these services, reducing developmental costs and to introduce more complex network functions by which users can communicate or manage information. U.S. Pat. No. 5,535,263, which is incorporated by reference to the extent necessary to understand the present invention, illustrates how an AIN can be used to enhance services.
One of the main distinguishing features of an AIN architecture with respect to a conventional switching network is that the intelligence or logic for executing value-added services is removed from the switch and is placed in one or more central computers called service control points (SCPs). AIN-capable switches, called service switching points (SSP), contain the functionality for communicating with the SCP. To make certain services more user-friendly, Intelligent Peripherals (IPe) may be provided, and these can be used to record prompts and announcements, provide voice recognition, voice-to-text functionality, and the like.
Value-added service calls can be originated from a local exchange (LE) or the SSP itself. In an AIN, the value-added service calls, or xe2x80x9ctrigger callsxe2x80x9d, are routed to the SSP which then opens a dialog with the SCP to guide the call to completion. The trigger call denotes the occurrence of a special condition which results in the telephone call being handled in a special way.
For certain types of toll calls and certain value-added services for which a subscriber is charged, an automatic message accounting (AMA) system is used to keep track of duration of the calls, accrued charges and other billing information. Typically, the AMA is resident in, or associated with, the SSP.
Typically, to provide special handling for a trigger call, the SSP suspends normal execution of the call, communicates with another network element to obtain special instructions, and handles the call according to the special instructions. Several types of triggers may be specified in an AIN-equipped switching system. They are classified as Originating Triggers, Mid-Call Triggers and Termination Triggers, depending on whether the special handling of the call is performed based on a triggering event at the time of initiation of a call, during the course of a call, or at the time of termination of a call. An example of an originating trigger is an 800-call trigger. This trigger is also called a Dialed Number trigger (DN trigger). Here, the special handling of the call is triggered by a user dialing the 800-number. In general, such numbers are translated to regular telephone numbers called Plain Old Telephone Service (POTS) numbers before they are routed to proper destination points via the traditional methods. Handling an 800-number call within an AIN network is described in detail in U.S. Pat. No. 5,425,090, which is incorporated herein by reference. Other examples of triggers are the Off-hook Immediate trigger (OHI), the Off-hook Delay trigger (OHD) and specific digits string trigger (SDS).
Communication between the different components of an AIN is performed through established protocols known to those skilled in the art. More particularly, communication within an AIN takes place between a host of switching systems, adjunct computer processors and other communicating components equipped with the capability to communicate using an out-of-band signaling method known as Common Channel Signaling (CCS). CCS is configured to carry network control information to and from various elements of the network. The AIN is described in detail in U.S. Pat. No. 5,247,571, which is incorporated herein by reference. For more information on intelligent telephony networks, see The Intelligent Network Standards: Their Application to Services (Igor Faynberg, Ed., McGraw Hill Series on Telecommunications, November, 1996). The details of the usage of CCS to control and manage a telecommunications network are given in U.S. Pat. Nos. 5,515,427 and 4,277,649, both of which are incorporated herein by reference. An example of the CCS signaling method is CCS No. 7 which also known as Signaling System 7, or SS7. SS7 is the name given to a suite of layered communication protocols that are used to access telephony databases, establish and maintain telephone calls and for other purposes. The part of the SS7 signaling protocol that is typically used by an AIN-equipped switching system to access telephony databases to obtain special instructions is called the Transaction Capabilities Application Part (TCAP).
FIG. 1 shows a simplified AIN system 100. System 100 includes a plurality of end users 102, such as a calling party or a called party, typically connected to an Service Switching Point (SSP) 104, 106, either directly or via one or more intermediary switches (IS) 108. The intermediary switch 108 may be operated by a local exchange carrier or may be a privately owned PBX switch, among others. The SSPs are usually connected to an end user with normal lines and trunks via protocols, such as Plain Old Telephone Service (POTS), Basic Rate Interface (BRI), and Primary Rate Interface (PRI). It should be understood that there may also be intermediary switches between an end user and the SSP, and that the SSP and the IS may belong to different carriers, which can be a local exchange carrier or an interexchange carrier.
When the SSP 104 or 106 encounters an AIN trigger for an incoming call, the SSP communicates with a Service Control Point (SCP) 110 to operate the requested service. The SSP and the SCP may communicate through the CSS7 network 112 which typically includes a number of Service Transfer Points (STPs). For voice-type functionality, one or more Intelligent Peripherals (IPe) 114 are connected to each of the SSPs 104, 106, which may also be connected to one another by one or more trunk lines 116. Each IPe 114 may include recording equipment for voice, fax and other media and is typically connected to a SSP using an ISDN trunk or line via PRI or BRI, or the like. It should also be noted that the IPe and the SSP may share the same platform, e.g., the same computer, but with different processes running on that computer. Communication between the SSP 104, 106 and the IPe 114 may be done with an AIN GR1129 IPe interface. As is known to those skilled in the art, an AIN GR1129 interface is an interworking between Transaction Capability Application Part (TCAP) protocol and Integrated Services Digital Network (ISDN) Q.931 protocol, where the SCP 110 communicates with the IPe 114 through the SSP using TCAP, and the IPe communicates with the SSP 104, 106 using Q.931. Each of the SSPs 104, 106 thus interworks TCAP and Q.931. Further information about the protocol for dealing with an IPe can be found in the GR-1129-CORE document; specifications for the AIN SSP switch procedures can be found in the GR-1298-CORE document; and information about the protocol between the SSP and the SCP can be found in the GR-1299-CORE document, all available from Telcordia (formerly Bellcore).
Normally, once the SCP helps connect the SSP and the IPe, the Ipe-resident applications are carried out without the IPe having to originate any calls. One option for using an IPe to originate a call, however, is to have the SCP send an AIN Analyze Route message to route the call to a service node, which then completes the connection to the called party. Once the connection to the called party is established, that service node can then merge the SSP-IPe connection with the connection to the called party by, for example, invoking the 2B channel call transfer specification in accordance with GR2865.
However, it is sometimes advantageous to use the AIN Send_To_Resource (STR) message, instead of the Analyze Route message, in such a manner that applications resident in the IPe originate the second call to establish a connection to the called party. This may be done, for example, to exploit capabilities inherent in AIN STR messaging schemes such as the capability to invoke new scripts in the IPe platform from the SCP without requiring SSP development, and the possibility of distributing data and control between the SCP and the IPe.
FIG. 2 presents a flow chart 300a and FIG. 3 present a call flow diagram 300b of the steps entailed in causing the IPe to originate a second call to connect the calling party to the called party. At step 302 a calling party dials a valid number and this is sent to the SSP. At step 304, the SSP encounters a valid AIN trigger, such as off-hook delay, a specific digit string trigger, or the like, and so sends a query to an SCP. At step 306, the SCP retrieves the customer account and recognizes that an IPe is needed for the call. At step 308, the SCP sends an AIN Send_to_Resource (STR) message to the SSP with the Destination Address parameter, which contains the network address of the IPe. This provides the SSP with access to the IPe.
At step 310, the SSP contacts the IPe and, at step 312, the IPe acknowledges the contact, thereby establishing a connection between the two. The connection between the SSP and the IPe is established using the typical GR1129 procedure, i.e., the SSP sends a Q.931 SETUP message to the IPe with a Facility Information Element (IE) containing the SendToIPResource invoke operation, and the IPe returns a Q.931 CALL PROCEEDING followed by a CONNECT message. This connection is called the B1 leg. At step 314, the IPe application processing originates the second call through the SSP to a called party. This connection is called the B2 leg. The B2 leg is internally bridged by the IPe to the B1 leg and so the calling party and the called party can potentially converse, exchange data, etc. During the call between the two parties, the B1 and B2 legs are maintained. During the call, the IPe and the SCP can potentially communicate, as per the service need, using AIN Call_Info_From_Resource and the Call_Info_To_Resource messages on the B1 side. The corresponding Q.931 message is a FACILITY message.
At the end of the call between the called party and the calling party, such as when the calling party hangs up, at step 316, the SSP sends a DISCONNECT message to the IPe, instructing the latter to tear down the call. It should be noted, however, that the reverse can happen, with the IPe sending the DISCONNECT message to the SSP. In either case, the DISCONNECT message results in the termination of the B1 and B2 legs, thereby releasing the two IPe ports used to sustain the call. At step 318, the SSP sends a Resource_Clear message to the SCP, advising the SCP that the SSP is done using the IPe for that call. The Resource_Clear message is sent to the SCP in the Response package if both the calling and the called parties have been torn down and no further instructions from the SCP are needed.
In the above example where the IPe originates the call to the called party, the call from the SSP to the IPe and the call from the IPe to the called party will be bridged for the entire duration of the call, even after the IPe""s use is over. This wastes IPe ports which cannot be used to attend to other calls. This also means that the SCP transaction has to remain open for the entire duration of the call. This wastes SCP resources, since the SCP transaction is open from the time that an AIN STR message is sent, until an AIN Resource_Clear message is received by the SCP. It should also be noted that AIN makes no specific provision for causing true answer indication to propagate back towards the calling party when the called party on the B2 side actually answers, and for the time of answer and disconnect for the call to be captured in the AMA record for billing.
The present invention is directed to merging two connections made at the IPe in those cases where (a) a Send_to_Resource message, or equivalent, is sent by the SCP to the SSP for establishing a first leg with the IPe, and (b) the IPe subsequently originates the call to the called party using two or more IPe ports for the duration of the call. In the present invention, the first connection from the SSP to the IPe and the second connection from the IPe to the called party are merged in the SSP when the IPe is no longer needed for the service for that call. This results in the SSP directly connecting the called and calling parties from that point onward, even though the IPe initially connected the two. After the call has been merged at the SSP, the connections to the IPe are discontinued, thereby freeing the IPe to field other calls and respond to other tasks.